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Abstract. Complex automated proof strategics are often difficult to vi- 
sualise, modify, and debug. Traditional tactic languages, often based on 
stack-bEised goal propagation, make it easy to write proofs that obscure 
the flow of goals between tactics and are fragile to minor changes in input 
or proof structure. Here, we address this by introducing a graphical lan- 
guage for writing proof strategies. Strategies are constructed visually by 
"wiring together" collections of tactics and evaluated by propagating goal 
nodes through the diagram via graph rewriting. Tactic nodes can have 
many output wires, and use a filtering procedure based on goal-types 
(predicates describing the features or "shape" of a goal) to decide where 
best to send newly-generated subgoals. In addition to making the flow 
of goal information explicit, the graphical language can fulfil the role of 
many tacticals using visual idioms like branching, merging, and feedback 
loops. We argue that this language enables development of more robust 
proof strategies and provide a prototype implementation in Isabelle. 



1 Introduction 

In existing tactic languages for proofs, it is often difScult to compose tactics in 
such a way that all goals are sent to the correct target, especially when different 
goals should be handled differently. Moreover, when a large tactic fails, it is 
hard to analyse where the failure occurred during debugging. If the structure 
of a tactic is difficult to understand, often the easiest way for a user to deal 
with failure is to manually guide the proof until the tactic succeeds (or becomes 
unnecessary), rather than correcting the weakness of the tactic itself. In this case, 
the proof is made more complicated and insight from this failure is not carried 
across to other proofs. Thus, a tactic language where it is easy to diagnose and 
correct failures will lead to better tactics and simpler, more general proofs. 

Firstly, we argue that many errors could have been found statically. The 
problem is that tactics are essentially untyped: they are functions from a goal 
to a set of possible suh-goals. In many programming languages, types are used 
statically to rule out many "obvious" errors. For example, in (typed) functional 
languages, a type error will occur when one tries to compose two functions which 
do not have a unifiable type. In an untyped tactic language, this kind of "round- 
peg-square-hole" situation will not manifest until run-time. 



Without a means of distinguishing goals, tactics have no choice but to rely 
on the order in which goals arrive. Small changes to tactics can lead to failures. 
For example, consider a case where we expect three outputs of tactic ti, where 
the first two are sent to ^2 and the last to ^3. A small improvement of ti may 
result in only two sub-goals. This "improvement" causes ^2 to be applied to the 
second goal when it should have been t^. The tactic t2 may then fail or create 
unexpected new sub-goals that cause some later tactic to fail. 

Finally, for errors that cannot be found statically, it is very hard to inspect 
and analyse the failures during debugging. In the above example, if t2 creates 
sub-goals that tactics later in the proof do not expect, the error will be reported 
in a completely different place. Without a clear handle on the flow of goals 
through the proof, finding the real source of the error could be very difficult 
indeed. 

In this paper, we address these issues by introducing a graphical proof strat- 
egy language. The primary aims of the language are (i) to improve robustness 
of proof strategies with static goal typing and type-safe tactic "wirings" and (ii) 
to improve the ability to dynamically inspect, analyse, and modify strategies, 
especially when things go wrong. 

The language is expressed using string diagrams, which 
provide a general way of describing composed processes. 
They originated with Penrose [IB] as a means of describing 
tensor contractions, but were later shown by Joyal and 
Street to be useful in a much more general context [O] . 
In our graphical language, tactics are represented by boxes 
and wires are labelled with goal- types. This is illustrated 
on the right for a variant of the rippling strategy |S] , which 
guides rewriting of the (conclusion of the) induction step 
case towards the induction hypothesis. 

Evaluation is done by propagating goal nodes toward the output wires using 
graph rewriting. 
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To define and manipulate string diagrams programmatically, we use a com- 
binatoric representation of string diagrams called string graphs [8_ . String graphs 
admit type-safe composition via pushout and type-safe transformation via double- 
pushout (DPO) graph rewriting. We provide a brief (non-categorical) back- 
ground on string diagrams, string graphs, and string graph rewriting in section 

El 

After introducing goal-types and typed tactics in section [Sj we describe the 
language and evaluation procedure for strategy graphs in section |4j In section [5] 
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we enrich this language with combinators and a notion of hierarchical evaluation. 
A prototype implementation in Isabelle is described in section [6 with examples 
in section [7] We discuss related and future work in sections [8] and 9j respectively. 



2 Background: String Diagrams and String Graphs 

The graphical proof strategy language is built on the mathematical formalism 
of string graphs. String graphs were defined in [5] (called open-graphs therein) 
to provide a rigorous rewrite theory for string diagrams. 




Fig. 1. A string diagram and its associated string graph 

A string diagram consists of boxes and wires. A box represents some kind of 
operation with multiple (distinguished) inputs and outputs, and wires express 
the composition of these boxes. Note that, unlike graph edges, these wires are 
allowed to be free (i.e. not connected to a box) at one or both ends. These free 
wires are used to express inputs and outputs of the diagram (see LHS of Figure 
[2|. Note that wires can even be connected to themselves to form circles. While 
this is an important feature of the general theory of string diagrams, circles will 
not be relevant for proof strategy graphs. 

String diagrams can be formalised as topological graphs with some extra 
structure. While intuitive, they are unwieldy if one wishes to develop a mecha- 
nised rewrite theory. To solve this problem, string graphs were defined to repre- 
sent string diagrams as "plain old" typed graphs with a well-defined notion of 
substitution: namely the double-pushout approach to graph rewriting. The main 
trick is to replace wires with chains of special vertices called wire vertices. 



X 




X 



We also introduce node-vertices, which represent "logical" nodes (aka boxes) 
in the diagram. 

We parametrise string graphs by a signature T, which defines a set of nodes 
and the types of their inputs and outputs. T consists of a set A4 of maps, a set O 
of types, as well as functions dom, cod : — )■ [O] that assign input and output 
types for each map, where [O] represents lists of elements of O. 

Henceforth, we will refer to chains of wire vertices simply as wires, when there 
is no ambiguity. There are a few things to note here. Firstly, wire-vertices carry 
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the type of a wire, so every connection between two node- vertices must contain 
at least one node- vertex. We do not allow wires to split or merge, so wire- vertices 
must have at most one input and one output. If nodes are not symmetric in their 
inputs or outputs, we distinguish inputs and outputs using edge types (ini, in2, 
outi, OUt2, . . .). 

Definition 1. If a wire- vertex has no in-edges, it is called an input. We write 
the set of inputs of a string graph G as In(G'). Similarly, a wire- vertex with no 
out-edges is called an output, and the set of outputs is written Out(G'). The 
inputs and outputs define a string graph's boundary, written Bound(G'). The set 
of vertices and edges not in the boundary of a string graph is called its interior. 

In [S] , the authors showed that string diagrams can be faithfully represented 
using string graphs, and that equations between string diagrams can be repre- 
sented by string graph rewrite rules. 



Note that in a string diagram equation, the input and output arities on 
the LHS and RHS always match. Also, we have implicitly stated which in- 
puts/outputs on the LHS correspond to which inputs/outputs on the RHS. We 
make this explicit in the string graph picture by requiring that the LHS and the 
RHS share the same boundary. 

Definition 2. A string graph rewrite rule L — > i? is a pair of graphs that share 
the same boundary, i.e. In(L) In(i?) and Out(L) = Out(i?). 

It is often convenient to encode this correspondence as a span of injective 
graph homomorphisms G i? — , in which case the boundaries need not be 
equal on-the-nose, but merely isomorphic as typed graphs. The site of a rewrite 
is marked by a matching. This is an injective graph homomorphism m : L ^ G 
with the additional property that edges in the rest of G may only connect to L 
via its boundary. In other words, there must be no edges connecting the interior 
of m(L) to G — m{L). 

We can now define rewriting in terms of a matching. Given a rule L — > R 
and a matching m : L ^ G: 

1. Rename L — > R to an equivalent rule L' — > R' such that L' = m{L) and 
the vertices/edges in the interior of R' are fresh in G. 

2. Let G' be G with the interior of L' removed. 

3. Form the rewritten graph as G' U R' . 

Since Bound(L') {— Bound(i?')) is never removed, it provides the "glue" 
for attaching i?' to the new graph. In categorical terms, step 2 is a pushout- 
complement and step 3 is a pushout. As the whole process involves two pushouts, 
this is called the double-pushout approach to graph transformation 
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For our purposes, we also allow vertex and edge data to carry free variables. 
For this case, in step 1 we additionally perform substitutions of free variables to 
instantiate L' — > R' . 

Often it is convenient to express families of string diagrams that 
have some repeated structure. When speaking about such families in- 
formally, it suffices to use ellipses to suggest repetition. 

However, when it comes to formalising these diagrams as families of string 
graphs or string graph rewrite rules, it is useful to be more precise. For this, we 
introduce the notion of a !-box (pronounced "bang-box"), which can be instan- 
tiated by performing a sequence of the following operations. 



A graph containing !-boxes is called a !-graph. The family of concrete graphs 
represented by a !-graph are precisely those that can be obtained by performing 
any of the 4 !-box operations zero or more times. 




We can represent infinite families of rewrite rules as a pair of !-graphs with 
corresponding !-boxes satisfying certain conditions to ensure that all concrete 
rules are valid. 





Like in the graph case, rules can be instantiated by performing the four !-box 
operations, with the additional condition that whenever an operation is applied 
to a !-box on the LHS, the same operation is applied to the corresponding !-box 
on the RHS. For more details on the definition and semantics of [-graphs, along 
with !-graph matching and rewriting, see |15j . 

Normally, when a !-box is copied the data on vertices and edges are copied 
verbatim. We extend the !-box language slightly by allowing free variables inside 
the box to be bound as fresh names using a (j) followed by the variable name. 
When a !-box is copied, any variables marked as fresh will be replaced with new, 
fresh free variables in the new copy. 
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3 Goal Types and Typed Tactics 



For a type r, let [t] be the type of finite hsts and {t} be the type of finite sets 
whose elements are of type r. 

Rather than considering all goals as members of one big type "goal" , assume 
that we have a partially ordered set of goal types Q. A particular goal type a G 5 
represents all goals with some particular features, which may include local prop- 
erties like "contains symbol X" , global properties like shared meta- variables, and 
tracing properties such as features of the parent goal. Since types are essentially 
predicates defined over goals, we assume the ability to take arbitrary meets and 
joins of goal types. 

Definition 3. For a A /? the meet of two goal types and _L the empty goal type, 
we say a and f3 are orthogonal if a A /3 = _L. 

Definition 4. A typed tactic is a function of the form: 

ttac : {[/3i] x [P2] x ... x [/3„]} 

where a and Pi are goal types, for all i. 

For our purposes, the usual notion of a tactic can be treated as a function of 
the form: 

tac : goal — > {[goal]} 

That is, it takes a single goal to a set whose elements are lists of subgoals 
(and possibly some other data such as a justification function) representing each 
evaluation of the (non-deterministic) tactic. 

For a given input type a and a sequence Pi of output types, we can lift tac to 
a typed tactic tac* : a — > {[/3i] x [/32] x . . . x [/3n]} as follows. First, for a goal list 
L, let piPi, . . . , L) be the set of all partitions of L into n lists {Li, . . . , 
where all of the goals in the i-th list have goal type Pi. Then: 

^ ip{Pi,---,Pn;tac{g)) if 5 is of type a 
1 otherwise 

If we disregard the order of goals in each list Li, this can be done without 
introducing non-determinism, provided the types Pi are all orthogonal. Tactics 
of the above form are the simplest constituents of strategy diagrams. 

Definition 5. Typed tactics of the form of equation ([T]) are called atomic tac- 
tics. 

We shall see examples of tactics that are not atomic later, when we discuss 
hierarchies. Henceforth, we will refer to typed tactics simply as tactics. 
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4 Definition and Evaluation of Proof Strategy Graphs 



It is possible to represent a proof strategy as a string diagram, where wires are 
labelled with goal types. 

Proof strategy diagrams contain three kinds of nodes. The first are tactic 
nodes, which we shall represent as boxes. 
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The second type of node is a merge node. These can have any number of 
inputs and one output. They are symmetric in their inputs, and adjacent merge 
nodes can be combined. 



merge := 



These two kinds of nodes suffice to define a proof strategy. Proof strategies 
have a "token-style" evaluation semantics, where goals move along wires and 
are processed by tactics. To model this evaluation using diagram rewrites, we 
introduce explicit goal nodes. These always have one input and one output wire 
labelled by a goal type a. The node itself contains a list of goals of type a. 
Whereas tactic nodes produce lists of goals, they only take one goal at a time 
as inpui[^ Therefore, we introduce identities for reducing lists to singletons. 




(3) 



Evaluation of a strategy graph proceeds via the eval meta-rule (Fig. |4]). 
This rule acts locally on a tactic and a goal singleton by applying the tactic on 
propagating subgoals to the relevant output wires. First, we'll show the case of 
a single input wire. Evaluation occurs in four steps: 



1. match the LHS of the eval rule, partially instantiating the rule 

2. evaluate the tactic function for the matched input and output types 

3. finish instantiating the RHS with the lists gsi produced by the tactic 

4. apply the fully instantiated rule(s) 



^ The use of goal-list and singleton lists for evaluation simplifies the evaluation se- 
mantics (compared with single goal nodes or evaluation of arbitrary sized goal-list). 
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Fig. 2. The eval meta-rule 



First, eval is matched as usual by finding substitutions for a, t, and 

g. At this point, the resulting rule L — > R is only partially instantiated, in that 
there are still free variables {gsi} in the RHS. To finish instantiating the rule, 
wc apply the associated typed tactic function. Suppose t = tac, we then lookup 
a function called tac with the signature: 

tac : a ^ x [P2] x . . . x [/?„]} 

Tactics need not be defined for every type signature. If the matched tactic is not 
defined, simply return the fail function fail((7) = {}. 

Next, we can apply the tactic to get a (lazy) set of evaluations E = tSLc{g). 
For each evaluation {gs[ , . . . , 55^) e E, we can instantiate a rewrite rule L — > R' 
by substituting gs^ for gs[ in R. 

Thus, for each evaluation of a given tactic, we get a matching fully-instantiated 
rewrite rule L — > i?' and a matching m : L — >■ G on the strategy graph. 

Example 1. Consider the conjecture even{2*n). This can be proved by induction 
with two base cases. Suppose the conjecture is on the input wire of a tactic node 
labelled with: induct : inductable — > {[^step] x [step]}. This is then evaluated 
as follows. In step 1, the variables are (partly) instantiated to cti: 

(Ti = {a inductable, ^1 ^ -istep, ^2 ^ step, t ^ induct, g ^ even{2 * n)}. 

Next, the underlying (untyped) induct tactic is applied to g creating the sub- 
goals: even{2 * 0), even{2 * 1) and even{2 * n) h even{2 * S{n)). Since the output 
types are orthogonal, the lifted tactic will return a set containing a single pair 

of goal-lists: {[eA;en{2 * 0), even{2 * 1)] , [even{2 * ri) h even{2 * 5(S'(n)))]). 
In the third step the instantiation of the rewrite rule is completed by 

(j = (Jil^{gsi [even{2*Q),even{2*\)\,gs2 ^ [even{2*n) h even{2* S{S{n))\}. 

Finally, the fully-instantiated rule can be applied to propagate the goal node 

through the tactic. 

Definition 6. A strategy graph is in evaluation normal form (ENF) if the only 
remaining goal nodes are on output wires of the graph. 



8 



A naive strategy for using the above procedure to generate graphs in ENF is 
as follows: 



1. use the above procedure to instantiate and apply eval 

2. unfold any (non-singleton) goal lists using the rules given by ([s]) 

3. repeat until eval yields no matches 

A graph may contain many goals (possible eval matches) . If there are no shared 
properties (e.g. meta-variables) between the goals, the result is independent of 
the application order modulo the goal order on the output wires. One may want 
certain evaluation strategies, such as 'evaluate the simplest goal first' or 'instanti- 
ate meta-variables in a certain order'. More sophisticated evaluation procedures 
can be achieved by configuring the rewrite engine with such evaluation and search 
strategy. However, the underlying strategy graph is independent of such details. 
Note that in the presence of feedback, a strategy is not in general guaranteed to 
terminate - this has to be proven on a case-by-case basis. If the graph is acyclic, 
it will always terminate (provided all of the tactic functions do). 

We handle tactic boxes with multiple input wires similarly, in that only one 
goal is processed at a time. The only difference is that a tactic can have distinct 
evaluation functions {taci, . . . , tac„}. The function tac^ is invoked when the 
matched goal node occurs on the i-th input wire of the tactic node. This position 
data will be important for graph tactics, introduced in the section [5j For atomic 
tactics, it is irrelevant, so all of the functions tac^ are taken to be identical. 

This evaluation "meta-rule" can be formalised over string graphs using a 
single !-graph rewrite rule. 





(4) 



Note how wire vertices carry the goal type information and edge data is used 
to distinguish the positions of input and output wires on the tactic node. The 
use of fresh-name binders on the indices j and k is crucial here to allow them to 
match distinct input and output edges. 

5 Combinators and Hierarchies 



An important aspect of any tactic language is the mechanism by which existing 
tactics can be combined.. Strategy graphs already admit a natural interpretation 
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for many familiar tacticals via graph combinators. For instance, if a strategy 
graph G has output wires with type /3i , . . . , /?„ and another strategy graph H has 
input wires of the same type, the strategy graph (G THEN H) can be obtained 
by plugging all of the outputs of G into all of the inputs of H. 

Suppose a strategy graph has a as input and output type. Then, we could 
introduce a feedback loop, or "trace" in categorical terminology, that will send 
goals of type a back to the input. Such a REPEAT combinator generalises both 
REPEAT.WHILE and REPEAT .UNTIL. Furthermore, if a captures exactly 
those goals for which the strategy graph will not fail, this becomes the traditional 
REPEAT tactical. 



[ G { 

GTHEN/f = ( ■■■ j REPEAT„(G) = 



We can also define a much richer notion of composition based on graph tactics 
that enables us to write hierarchical proof strategies (in the spirit of, e.g. Hi- 
Tacs |2I17| ) and elegantly express branching strategies using OR and ORELSE 
combinators. 

Definition 7. A graph tactic is a typed tactic 

G-tac, : a, ^{[/3i]x [/32]x...x [/?„]} 

where G is a strategy graph whose i-th input is of type ai and whose output 
types are /3i, . . . ,/3„. 

For a goal the evaluation G-tsiCi{g) is computed as follows: 

1. add [g] to the i*'' input wire of G 

2. use the evaluation rule Q to produce zero or more graphs G' in ENF 

3. for each G', return a tuple {gsi, . . . , (;s„), which gSj is the list of all goals 
remaining on the j*^ output edge of G' 

A common LCF tactical is the OR combinator, where OR(taci, tac2) either 
applies tactic taci or tactic tac2. We can lift this tactical to the level of proof 
strategy graphs, by evaluating both graphs and taking the union of the resulting 
evaluations. ORELSE is similar, except it will short-circuit the second tactic if 
the first succeeds. For two graphs G and H with the same input and output 
types, we define the following typed tactics for OR and ORELSE. 

(G OR HUg) 
(G ORELSE H)i{g) 




G-taLC.,{g) U i?-taCj(.g) 

fG-tac,(g) if G-tac,(5) ^{} 
]H-taCi{g) otherwise 
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A consequence of the recursive evaluation of nested graphs is that different 
search and evaluation strategies can be applied to different parts of a proof, by 
attaching special strategies to graph tactics. One can easily turn a graph tactic 
into a rewrite rule, and an OR/ORELSE conibinator into a set of rewrite rules, 
by lifting the tactic node into a graph with the same boundary as the graph it 
encapsulates. This can be useful for interactive usage. 



G-tac 




(Gi OR Gz 




Note that the THEN combinator and OR/ORELSE combinators rely on 
strict matching for input/output types. One could implement these in a more 
flexible manner by using typing information to automatically permute inputs 
and outputs to fit graphs together, where possible. If the relevant types are 
orthogonal, this can even be done without introducing any non-determinism. 

In a longer version of this paper, currently under development, we plan to 
formalise the combinators outlined here together with several variations of them. 

6 Implementation 

A prototype has been implemented for the Isabelle theorem provei|^ 

Proof Representation In Isabelle, all subgoals are stored within a single 
thm type, e.g. if subgoal G and H remain to prove the goal F, then this is 
stored internally as G H F. When G and H are discharged, then only 
F is left and the proof is complete. Inspired by the way Isabelle/Isar handles 
structured proofs, we have created a proof representation where each subgoal is 
stored separately. In order to discharge G =^ H F, having proved G and 
iJ, we use backwards resolution in an "export phase" which turns our internal 
representation into a thm that can be used as an Isabelle/Isar tactic/method. 
This integration is still under development, and some features of Isabelle thm 
objects (e.g. schematic variables) are not yet supported. 

Proof Strategy Graph Representation String graph representation and 
rewriting is implemented using the Quantomatic |14j library. Among other things, 
Quantomatic provides functors for defining graph theories, given expressions for 
vertex and edge data, along with functions for matching and unifying data. The 
core rewriting engine is implemented in Poly/ML - the implementation language 
of Isabelle. First, we have combined these two tools, by creating an Isabelle the- 
ory which includes the Quantomatic core. On top of that we have implemented 
the theory described in the previous sections for proof strategies. 

In addition to the graph, a separate proof object is used, which keeps track of 
each goal, and their internal relationship. An atomic tactic contains an Isabelle 
tactic, while a graph tactic uses a graph stored in the Isabelle context. 



See https : //github. com/ggrov/psgraph/tree/itpl3 
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Fig. 3. Screenshot of GUI. Left: Drawing GUI. Right: Interactive Execution GUI. 

Goal types are represented by a narae and a set of named features. To encode 
a feature, we have defined a set of feature types, which consists of a name and 
a matching function on the goal, which may take some arguments. A goal then 
matches a goal type if all the features in the goal type matches. For example, 
one supported feature is the top level symbol of a goal's conclusion. This is 
represented by a named feature type topJeveLsymbol, which accepts the name 
of the symbol as argument. For example, (A, topJeveLsymbol) means that A is 
the top-level symbols and {conj, {(A, topJeveLsymbol)}) is the conj edge in the 
example in section [Tj 

The prototype implementation deviates from the theory in that relevant 
rewrite rules are generated on-the-fiy to match the neighbourhood of a given 
tactic node. This is to overcome the fact that !-boxes in Quantomatic do not yet 
support fresh-name binders, as used in the meta-rule at the end of section[4] The 
current representation also does not distinguish input and output edge order on 
nodes. However, this has little effect on the strategies tested, as type information 
typically suffices to direct goals to the appropriate input /output. 

Executing Proof Strategies Proof strategy graphs can be registered in 
advance and invoked via an Isabelle method called proof_strategy, which uses a 
variable strategy holding the name of the active strategy. Thus, a strategy graph 
can be invoked using the following command in an Isabelle/Isar proof mode: 

using [[strategy — ...]] apply proof .strategy 

The goals on the output edges of the given strategy graph become new sub-goals 
after executing this method. 

Implementing Graphs Strategy graphs can be implemented directly at 
the ML-level using the following procedure: 

1. Implement the goaUypes and declarate I/O types for tactics. 

2. Lift typed tactics into graphs and combine them into a proof strategy graph 
using available combinators. 

3. Register the graph with a name in the Isabelle theory. 

Drawing Graphs A more natural way to work with graphs is to draw them 
in a GUI. After a strategy graph is created in our graph editor (see LHS of Fig. 
[3|, it can be saved as a file (say intro.qgraph). This can then be imported to 
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Isabelle, and is automatically registered with the base name of the file, in this case 
intra. Our ultimate goal is to extend the GUI support so that strategy graphs 
can be written and modified inline, rather than needing to be continuously saved 
and re-loaded. One still have to implement goal-types and associate a name for 
each of the tactics used in this case. 

Debugging Interface There is also an interactive version of the proof_strategy 
method, called proof_strategy_interactive. This method uses a socket to commu- 
nicate with a GUI written as an Eclipse plug-in - and thus works best with the 
Isabelle/Eclipse version of the Isabelle PID^ However, it can still be used from 
e.g. Isabelle/jEdit. This interface is shown on the right hand side of Figurejsj and 
contains three buttons: one for back-tracking, one to terminate the proof pro- 
cess; and one for the next step. When terminating a partial proof, the remaining 
sub-goals become new sub-goals. This interface is mainly used for debugging, 
testing and analysis of a proof strategy. 



7 Tool Illustration: an Introduction Proof Strategy 

To illustrate the language and the tool, we will use "failure-analysis" to develop 
a version of the well-known introduction tactic. Although this is well-understood 
and straightforward to implement in standard tactic languages, it is sufficiently 
simple to illustrate some properties of the language and tool for the space avail- 
able here. 

Example 2 (First Version). The strategy works on any goal, thus we uses this 
T goal-type as an input. Next, we introduce three new goal-types: imp which 
holds for a goal with a conclusion of a logical implication; conj which holds for 
a goal with a conclusion of a logical conjunction; and other which "negates" 
the previous two, that is, it holds for a goal with a conclusion that is neither a 
conjunction nor an implication. Next, we introduce some atomic tactics: 

— split : any {[imp] x [conj] x [other]} is an identity tactic used to filter 
the goals according to their goal-type. 

— impi : imp — > {[other]} is the implication introduction tactic. 

— conji : conj {[other]} is the conjunction introduction tactic. 

and draw the left most diagram of Fig. [4j 

Example 3 (Second Version). The strategy works well for goals such as A — > B 
and A /\ B. However the tool will fail for goals such as A — > B A C, since the 
output goal of impI will be BAC which fails for the other type. Thus, we change 
the output to any, so that impI : imp — {[any]} and conjI : conj — > {[any]}. 
Moreover, the intuition behind this strategy is that goals on the output should 
not have a conclusion of the shape of a conjunction or implication which it will 
for the goal A — > BAC. Thus, we introduce the output from impI and conjI 
are fed back into split. This is the middle diagram of Fig. [4j 



See https : //github. com/ cindriusvelykis/isabelle- eclipse 
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Fig. 4. Intro strategy graphs 



Example 4 (Third Version). We can also analyse the graph to easily spot a 
missing case. E.g. consider running the tool on the goal A — > B A (Vx. P x). 
On termination, the output on the other wire will contain the goals A, B and 
Vx. P X. Let's assume that these eventually reaches a tactic which do not support 
universal quantifiers. By inspecting the execution, one can easily spot where our 
strategy failed. Thus, we introduce a new goal-type all, which succeeds when the 
conclusion of the goal has the shape of a universal quantifier. Then, we update 
split into split : any {[imp] x [conj] x [all] x [other]}, and other so it 
also fails when the conclusion starts with a universal quantifier. The resulting 
strategy is the right-most diagram of Fig. |4[ The same approach can be used to 
discover the remaining cases of the introduction tactic. Note that if the input 
type of the target does not support universally quantified goals, then this error 
would have been found statically during composition (causing evaluation to fail). 



8 Related Work 

We often distinguish between procedural proofs, where a proof is described as 
a sequence of tactic applications (i.e. function composition), ignoring the goals; 
and declarative or structured proofs, where the proof is described in terms of 
intermediate goals (goal islands), and the actual proof commands are seen more 
as a side issue. In our language, these two views are merged in the sense that 
the goal-type and goals on the wires create a declarative view, while the graph 
as a whole gives a procedural view of how tactics are composed. 

Autexier and Dietrich [3] have developed a declarative tactic language on top 
of a declarative proof language, where a proof schema is created together with 
variables that can be instantiated by matching when a particular goal is applied 
to it. Their work seems closer to the declarative view, whilst we believe that our 
work is more general in terms of composing smaller strategies. 

Similarly, there have been several attempts to create declarative tactic lan- 
guages on top of procedural tactic languages |llllOj . Asperti et al [T] argues that 
these approaches suffer from two drawbacks: goal selection for multiple sub-goals, 
and information flow between tactics. We believe that our lifting to goal-types 
and compositions in terms of them addresses both drawbacks. 

The ability to write hierarchical proofs is also supported in some tactic lan- 
guages, most notably HiTacs |2ll7j . By utilising goal types we can write more 
general hierarchies compared with HiTacs, since we allow multiple input edges 
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and each input edge may contain multiple goals, whilst HiTacs only allows one 
input goal for a hierarchy. Like us, the authors develop a general theory for their 
tactic language, independent of the underlying theorem prover. 

The goal types in our language can be seen as a lightweight implementation 
of pre/post-condition as in proof planning [4], with the additional property that 
the language captures the flow of goals. The work did in fact initially start as a 
new version of the IsaPlanner proof planner |7, , but a proof represention closer 
to Isabelle turned out to be more practical. In the future we plan to include 
proof critics [S] into the language, which can help automate patches to common 
failures. In particular, the use of goal- types to constrain the search for missing 
lemmas. 

It is important to note the difference with the field of diagrammatical rea- 
soning, as in e.g. 12J and [?], where diagrams are the objects of interest for 
reasoning rather than the means of capturing the reasoning process. 

9 Conclusion and Future Work 

By lifting proof strategies to the level of goal-types rather than the level of goals, 
we are able to write more robust strategies, and no longer rely on the number 
and order of sub-goals resulting from a tactic application for tactic composition. 
Thus, the problem of goal selection/focus/classification when composing tac- 
tics, as highlighted in pi, is significantly improved. Since composition of proof 
strategies is also at the level of goal-types, we increase type safety and enable 
better static analysis. The use of graphs to represent the flow of goals further en- 
ables visualisation of partially evaluated proofs and improves debugging, failure 
analysis and failure patching. 

Consider, for example, the rippling strategy from section [l] In a traditional 
tactic language, it would have been easy to mistakenly send all goals to simp 
before rippling was attempted, which could break the syntactic requirement of 
rippling. Such mistakes are inherently difficult to find, and we believe that our 
language greatly simplifies this kind of situation. 

We are working on improving the theory to take advantage of the partial 
order structure to admit sub-typing and type unification on wires. Further, we 
would like to move the implementation closer to the theory by using built-in 
!-box mechanisms, rather than generating rules on the fly. We are also working 
on improving the implementation itself by providing better integration of the 
tools for drawing and inspecting strategies, as well as adapting the code to work 
with other underlying theorem provers. 

An additional motivation for the language has been as a language for learning 
high-level proof strategies from exemplar proofs, first motivated in [5]. With 
partners on the AI4FM project (www.ai4fm.org) we are working to support 
this form of analogical reasoning. In particular, we are working on extracting 
strategy graphs from Isabelle proofs, which we then generalise by graph rewriting 
and transformations. Automatically extracting new goal types is an important 
part of this process, and are also working on using the partial order for the goal 
types in order to support sub-typing. 
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